The present invention relates to a firmware assist block and more particularly to hardware that performs firmware tasks related to command and context management of a data controller.
A data controller is included in the electronics of a peripheral device such as a CD-ROM or a hard drive. In FIG. 1, a peripheral device 100 is coupled to a host adapter board (xe2x80x9cHABxe2x80x9d) 110 included in a host 120. Peripheral device 100 includes a data storage medium 130 that is coupled to a servo and read/write channel 140. Servo and read/write channel 140 is coupled to a data controller 150 and a microprocessor 160. Data controller 150 is coupled to buffer memory illustrated as a RAM 170 and a peripheral bus 180. Another memory, shown as SRAM 190, is coupled to microprocessor 160 as local storage.
The general function of data controller 150 is to process commands from a requester or initiator, such as host 120. Host 120 can be a personal computer, workstation, server or other peripheral device. Data controller 150 performs data transfers associated to those commands with the data storage medium 130 of peripheral 100, e.g., magnetic or optical disk. In more detail, data controller 150 processes the commands to configure itself for the associated data transfers. The commands may not request data transfers, but may request status of the peripheral device. Data controller 150 must also process these commands.
Different bus architectures and protocols exist for peripheral bus 180 that provide the commands. Such architecture and protocols are defined by, for example, ATA, ISA, IDE, USB, SCSI and Fibre Channel. For example, a SCSI command known as control descriptor block (xe2x80x9cCDBxe2x80x9d) includes an operational code consisting of a group code and a command code, a logical unit number, logical block addresses (LBAs) if required, a transfer length value if required and a control byte. The transfer length value specifies the number of blocks (or other data units) that are to be transferred with an associated command. Thus, data controller 150 must be able to at least process one of those command protocols.
Typically, data controller 150 processes the commands using firmware. Use of firmware, however, requires increased storage space associated with the data controller. As a result, the physical requirement and cost of data controller 150 are increased. The firmware also requires microprocessor 160 intervention, which prevents microprocessor 160 from performing other tasks and requires more time to process the data transfer due to the time needed to execute the firmware. For example, a data write to data storage medium 130 may be too large for data controller 150 to process while connected to SCSI bus 180. Microprocessor 160 must be interrupted and used to program data controller 150 to disconnect itself SCSI from bus 180. When data controller 150 is capable of receiving more data, the microprocessor is interrupted again and then programs data controller 150 to reconnect itself to SCSI bus 180. Some data writes may require this disconnect/reconnect sequence numerous times. These disadvantages associated with microprocessor 160 limit the data transfer rate between host 120 and peripheral 100. This limiting of the data transfer rate is contrary to the present industry effort to increase that data transfer rate.
To further illustrate, some data transfers can have a sequence of commands where the LBAs are within a certain range. In this case, microprocessor 160 is interrupted numerous times to process the commands associated with the LBAs. This is a particularly wasteful use of microprocessor 160 resources since the LBAs are located within that range and the data controller does not take advantage of this situation.
Therefore, a need exists for a data controller that can provide a data transfer rate greater than a purely firmware oriented data controller, and at the same time minimize the required memory space. The present invention meets this need.
The present invention includes a Command Queuing Engine (CQE) that is a firmware-assist block which processes some of the firmware tasks related to command and context management preferably for SCSI. When enabled, the CQE will decode SCSI commands as they arrive, and determine if DMA contexts can be automatically configured and started to transfer the data for those commands. The CQE can also program DMA contexts to automatically return status information either after the disk has completed a transfer (as in non-cached writes) or after the DMA transfer is completed (as in reads or cached writes). The CQE also utilizes a buffer-based linked-list to queue the SCSI commands as they arrive for future DMA context configuration.
The CQE assists the firmware in achieving a very high input/output per second (xe2x80x9cIO/Secxe2x80x9d) rating when receiving sequential commands. Sequential commands are defined as commands whose parameters are the same except for their respective LBA, Queue Tag and length; however the LBA is within a predetermined range from the end of the previous command""s transfer LBA. As sequential commands arrive, Transfer Extend (TE) entries are created in a Transfer Extend linked-list (xe2x80x9cTE listxe2x80x9d) and then the SCSI commands are discarded. The CQE retrieves TE entries from the TE list one at a time. Then, the CQE programs corresponding DMA contexts to transfer data and status as the contexts and disk allow. To handle a thread of sequential commands, the microprocessor only receives non-error interrupts at the start of the thread (to aid in the initial DMA and data formatter (xe2x80x9cDFxe2x80x9d) context setups), optionally in the middle when the DF needs to change tracks and at the end when a new sequential thread is pending.
The CQE also provides assistance for the firmware to re-order queued commands. By default, the CQE handles commands in the order they arrive. However, the firmware receives the interrupts required to allow re-ordering of the commands into sequential threads or for the purpose of reducing disk seek times. The firmware can manage multiple TE lists to optimize how sequential threads are built as commands arrive. Random commands or non-Read/Write commands are merged into the TE list such that the microprocessor can handle those commands in the time frame it determines as appropriate.
The present invention provides automated recognition and linking of commands belonging to a common thread, i.e., are sequential. The present invention also provides extensive thread boundary information and flexible firmware control for reordering commands. Automatic TE entry generation and storage to buffer memory, and automatic TE retrieval from the buffer memory and execution of entire command threads are further features provided by the present invention. As a result, bus command response latency is decreased by reducing the delay for the command to be started and at the end of the data transfer for status to be sent. Disk efficiency is increased by reducing the latency to back-fill or empty a buffer memory segment of data that will be transferred. Furthermore, the present invention is a low-cost trade-off between hardware and firmware functionality.